Task: Specify The Test Object Intake (AST)
Purpose
The preparation of the intake of the test object so that testing can start as soon as possible after delivery of the test object.
Relationships
Main Description

Method of operation

This activity contains the following steps:

  1. Creating a checklist for the test object intake
  2. Creating a pre-test test script.

Products

  • Checklist of test object intake test
  • Pre-test test script.

Tools

  • Testware management tool
  • Test data tool
  • Test design tool
  • Automated test execution tool
Steps
1. Creating a checklist for the test object intake

At a certain point, the test team takes delivery of the test object. This first activity has the aim of establishing whether the delivery of the test object is complete, i.e. that it contains what was agreed with the supplier of the test object – no more and no less.

The test object usually consists of all kinds of software components (each with a particular version), but a user manual and installation guide, too, for example, may be part of it. The tester documents in the checklist which parts are expected with the delivery. Besides information on the test object itself, the checklist also contains questions on the delivery information. It should be apparent which changes the delivery contains and which parts are related to which change. This prevents the test team from receiving changed software parts, while they have no change proposal and therefore no test planned for it.

This occurs with specialist packages, in particular, because the supplier implements the change proposals of a number of customers simultaneously, but only provides feedback to each customer individually concerning the changes requested by them.

2. Creating a pre-test test script
After installation of the test object, a pre-test takes place in order to determine whether the test object is good enough to start testing. In this activity, the testers prepare this pre-test by creating a test script. This can involve several degrees of thoroughness. Below are a few examples:

  • Checklist with all the functions, which should all be accessible
  • For a number of representative functions, a simple test case with valid input (“good case”) is specified
  • Specification of test cases solely aimed at integration to check that the various parts can communicate with each other. The data-cycle test is a good choice for this (see Data Cycle Test (DCyT).

The test cases may be obtained from the regular tests, but the results check is much more flexible. For example, it is not important for the pre-test that the test case delivers a correct result, as long as it delivers a result and does not crash, for example.

Examples:

  • For a banking application, the pre-test consists of a script of 25 end-to-end test cases.
  • With another financial organisation, the pre-test takes a day in which a tester executes the test cases which contain the most important functionality.
  • A telecommunications organisation requests the supplier of the software to execute a number of end-to-end test cases as a pre-test.
More Information